sad
1. Proposta d’idea del projecte: AdMe
1.1 Introducció
AdMe és una aplicació per crear, buscar i compartir anuncis de particulars o autònoms basats en categories.
1.2 Ojectiu de l’app i quines necessitats resol
L’objectiu d’AdMe és posar en contacte oferents, particulars i autònoms de tota mena de serveis o compra-venda d’objectes, amb usuaris interessats. Permet als usuaris crear anuncis i compartir-los a través de l’app, així com buscar, filtrar i trobar ofertes o anuncis d’altres usuaris.
Aquesta aplicació respon a la necessitat d’un mercat mòbil senzill i dinàmic per a particulars i autònoms, oferint una plataforma on els usuaris poden anunciar-se o buscar ofertes de manera segura i transparent.
1.3 Estudi de mercat
1.4 Target
El target d’AdMe és molt variat, arribant a un públic comprès entre els 18 i els 50 anys.
2. Especificacio de requisits
2.1 Requisits funcionals
I. Gestio d’usuaris
Requeriments relacionats amb l’autenticació, perfil i accions generals dels usuaris.
-
RF01: Login. L’usuari ha de poder iniciar sessió a l’aplicació amb el seu correu electrònic i contrasenya i sempre que estigui activat.
-
RF02: Registre. L’usuari ha de poder registrar-se per poder utilitzar l’app. Un nou usuari enregistrat, per defecte està en estat desactivat.
-
RF03: Recuperar contrasenya. L’usuari ha de poder recuperar la contrasenya en cas d’oblit.
-
RF04: Editar perfil usuari. L’usuari ha de poder modificar les dades del seu perfil, inclosa la seva foto.
-
RF05: Logout. L’usuari ha de poder tancar la sessió de manera segura.
-
RF06: L’administrador ha de poder canviar l’estat (activat o desactivat) dels usuaris enregistrats.
-
RF07: L’administrador ha de poder eliminar un usuari.
-
RF08: L’administrador ha de poder llistar tots els usuaris.
-
RF09: L’administrador ha de poder modificar un usuari.
II. Gestio de categories
Requeriments relacionats amb la creació, visualització i gestió de Categories.
-
RF10: Crear nova categoria. l’usuari ha de poder crear una nova categoria de tipus “Proposta” per defecte que contingui com a mínim un nom, una imatge i una descripció.
-
RF11: Llistar categories. L’usuari ha de poder veure una llista de totes les categories existents de tipus “Oficial”.
-
RF12: Filtrar categories. L’usuari ha de poder cercar categories pel seu nom i veure els resultats ordenats alfabèticament.
-
RF13: Ampliar informació de categoria. L’usuari ha de poder seleccionar una categoria i veure tota la informació associada (nom, imatge i descripció).
-
RF14: Modificar categoria. Només l’usuari administrador ha de poder modificar el nom, la imatge, la descripció i el tipus (“Oficial”, “Proposta”) de qualsevol categoria.
-
RF15: Eliminar categoria. Només l’usuari administrador ha de poder eliminar una categoria, sempre que no tingui anuncis associats.
-
RF16: Filtrar anuncis per categoria. L’usuari ha de poder veure només els anuncis que pertanyen a una categoria seleccionada.
III. Gestio d’anuncis
Requeriments relacionats amb la creació, visualització i gestió anuncis.
-
RF20: Crear nou anunci. L’usuari ha de poder crear un nou anunci que contingui, com a mínim, una imatge, títol, descripció curta, preu, data de creació, autor, numero telefon autori categoria.
-
RF21: Llistar anuncis. L’usuari ha de poder veure una llista de tots els anuncis existents, mostrant-ne la imatge i títol, amb un botó per ampliar informació.
-
RF22: Filtrar anunci per camps. L’usuari ha de poder filtrar els anuncis basant-se en qualsevol dels camps disponibles dels anuncis (com el títol, l’autor, o la data de creació, entre d’altres).
-
RF23: Ordenar anuncis per camps. L’usuari ha de poder ordenar la llista dels anuncis segons qualsevol camp disponible, com el títol, la data de creació o l’autor.
-
RF24: Ampliar informació del anunci. L’usuari ha de poder veure tots els detalls d’un anunci seleccionat (títol, imatge, descripció, autor, data de creació.
-
RF25: Modificar anunci. Només l’usuari que ha creat un anunci, o l’administrador, han de poder modificar-ne la informació, excepte l’autor, la data de creació, les valoracions i els comentaris.
-
RF26: Eliminar anunci. Només l’usuari que ha creat un anunci, o l’administrador, han de poder eliminar-lo.
IV. Requisits de negoci
Requeriments de negoci addicionals per al funcionament de la nostra aplicació.
-
RF27: L’administrador a de poder “activar” o fer “Oficials” les propostes de categorías modificant les.(Les categories poden ser de 2 tipus: “Oficial” i “Proposta”).
-
RF28: L’administrador a de poder llistar totes les categories de tipus “Proposta”.
2.2 Proposta de millora
Proposem per a millorar en futures versions de l’aplicació una funció de xat a través la cual els usuaris puguin interactuar, conversar i negociar desde la mateixa aplicació.
2.3 Requisits no funcionals
I. Requisits Tècnics part frontend Mobile
-
RN01: L’aplicació s’ha de desenvolupar utilitzant l’IDE Android Studio, implementant el llenguatge Kotlin per crear una aplicació nativa compatible amb dispositius Android.
-
RN02: L’aplicació ha de tenir l’arquitectura MVVM (Model-View-ViewModel) i el ViewModel ha de gestionar l’estat de l’aplicació amb MutableStateFlow i StateFlow.
-
RN03: S’ha d’utilitzar Jetpack Compose per implementar la interfície gràfica.
-
RN07: S’ha d’utilitzar el git/gitlab per implementar el projecte en equip de forma òptima i adient.
-
RN08: S’han de fer servir les següents branques: main/master, developer i branques per features, bugfix, etc.
-
RN09: Tots els merges de funcionalitats s’han de fer per merge-request a developer.
-
RN10: Les branques fusionades s’eliminen després del merge-request.
II. Requisits d’Interfície (UI/UX, Accessibilitat) frontend Mobile
-
RN11: L’app ha d’estar en català, castellà i anglès.
-
RN12: La interfície de l’usuari ha de complir amb les directrius de disseny Material Design. El disseny visual ha de ser atractiu amb coherència de colors, fonts, icones, bona distribució i agrupació de components. Mateix disseny per totes les pantalles.
-
RN13: Responsive: En cas de variar la grandària de la pantalla del mòbil (no cal per tablet), s’ha d’adaptar el contingut de forma proporcionada.
-
RN14: Usabilitat (UX): Interfície amigable, efectiva, intuïtiva i eficient. No pot haver-hi passos innecessaris entre el que vols fer i com fer-ho. Ha de quedar molt clar què es pot fer. També cal que tingui coherència amb les funcionalitats disponibles i no disponibles en cada moment.
-
RN15: App accessible: Els elements interactius han de tenir etiquetes descriptives per facilitar-ne l’ús.
-
RN16: S’ha d’utilitzar el menú Bottom Navigation per a la navegació a les funcionalitats principals.
III. Requisits operatius frontend Mobile
-
RN17: L’app s’ha de poder executar en qualsevol emulador o dispositiu mòbil amb sistema operatiu Android.
-
RN18: Fluïdesa: L’app ha de respondre a les entrades de l’usuari en tot moment. Això vol dir que en cap cas pot quedar “congelada” mentre realitza qualsevol operació.
-
RN19: Gestió d’excepcions: Totes les possibles situacions excepcionals han de quedar gestionades de forma correcta i proporcionar missatges d’errors descriptius i útils per a l’usuari quan falli.
-
RN20: El codi ha de ser optimitzat, eficient i sense redundàncies.
-
RN21: S’han d’utilitzar les classes, interfícies i mètodes i packages de forma òptima i adient. RN22: Qualsevol entrada per teclat per part de l’usuari ha de validar-se i filtrar-se per garantir que les dades recollides siguin correctes, coherents i segures.
-
RN23: Totes les capçaleres de mètodes i classes han d’estar degudament comentades en format JavaDOC.
-
RN24: Els logs han d’estar disponibles per al monitoratge i depuració.
-
RN25: L’aplicació ha de garantir que només els usuaris amb els permisos adequats puguin accedir a determinades funcionalitats.
-
RN26: La capa presentació ha d’estar ubicada en el frontend Mobile.
-
RN27: La comunicació entre el frontend Mobile i el backend s’ha de portar a terme mitjançant els principis REST
-
RN28: L’administrador pot fer totes les funcionalitats.
3. Guions per actors
3.1 Usuari Anonim
| Actor | Usuari Anonim |
|---|---|
Descripció |
Aquest actor representa un usuari que encara no s’ha autenticat independentment de si s’ha registrat prèviament i no té accés a l’aplicació, només al login i registre. |
Guió |
RF01: L’usuari anònim pot iniciar sessió amb correu i contrasenya i sempre que estigui activat. RF02: L’usuari anònim pot registrar-se per poder utilitzar l’app. (estara per defecte desactivat). |
3.2 Usuari autenticat
| Actor | Usuari autenticat |
|---|---|
Descripció |
Aquest actor representa un usuari que s’ha autenticat havent-se registrat prèviament i té accés a les funcionalitats bàsiques de l’aplicació. |
Guió |
RF03: L’usuari pot recuperar la contrasenya en cas d’oblit. RF04: L’usuari pot editar el seu perfil (incloent foto). RF05: Logout. L’usuari ha de poder tancar la sessió de manera segura. RF10: Crear noves categories amb nom, imatge i descripció. RF11: Veure la llista de categories existents. RF13: Ampliar informació de categories seleccionades (nom, imatge i descripció). RF16: Veure anuncis agrupats per categories seleccionades. RF20: Crear nous anuncis amb detalls (imatge, títol, descripció, preu, categoria, etc.). RF21: Veure una llista de tots els anuncis existents. RF22: Filtrar anuncis basant-se en camps específics. RF23: Ordenar anuncis segons camps (data, autor, etc.). RF24: Ampliar informació d’un anunci seleccionat. RF25: Modificar anuncis creats per l’usuari. RF26: Eliminar anuncis creats per l’usuari. |
3.3 Administrador
| Actor | Administrador |
|---|---|
Descripció |
Aquest actor té tots els permisos incloent permisos especials per gestionar l’aplicació. |
Guió |
RF03: L’usuari autenticat pot recuperar la contrasenya en cas d’oblit. RF04: L’usuari autenticat pot editar el seu perfil (incloent foto). RF05: Logout. L’usuari ha de poder tancar la sessió de manera segura. RF06: Activar o desactivar usuaris registrats. RF07: Eliminar usuaris. RF08: Llistar tots els usuaris. RF09: Modificar dades dels usuaris. RF10: Crear noves categories amb nom, imatge i descripció. RF11: Veure la llista de categories existents. RF13: Ampliar informació de categories seleccionades (nom, imatge i descripció). RF14: Modificar categories existents. RF15: Eliminar categories sense anuncis associats. RF16: Veure anuncis agrupats per categories seleccionades. RF20: Crear nous anuncis amb detalls (imatge, títol, descripció, preu, categoria, etc.). RF21: Veure una llista de tots els anuncis existents. RF22: Filtrar anuncis basant-se en camps específics. RF23: Ordenar anuncis segons camps (data, autor, etc.). RF24: Ampliar informació d’un anunci seleccionat. RF25: Modificar anuncis creats per altres usuaris. RF26: Eliminar anuncis creats per altres usuaris. RF27: Poder “activar” o fer “Oficials” les propostes de categorías. RF28: Poder llistar totes les categories de tipus “Proposta”. |
6. Disseny de pantalles
7. Disseny de la Base de dades
7.1 Justificació BBDD
El disseny de BBDD que hem escollit és de Base de dades relacional amb (SQL), la nostra decisió es basa en els següents punts principals:
-
La proposta de negoci: La nostra proposta de negoci és més simple d’aplicar en una BBDD relacional com SQL.
-
Practica i experiencia: Estem més acostumats a treballar amb BBDD relacionals com SQL i, per tant, tenim molta més pràctica i experiència, cosa que facilitaria la resolució de problemes futurs.
-
BBDD no relacional no requerida: No és necessari per a cap aspecte de la nostra app utilitzar una BBDD no relacional com MongoDB.
Seguiment dels sprints
Sprint 1
3. Anàlisi del treball individual.
Carlos
-
Hores dedicades: 28h
-
Tasques realitzades
-
Entitat User backend
-
Entitat Ad backend
-
Entitat Category backend
-
Entitat User frontend
-
Entitat Ad frontend
-
Entitat Category frontend
-
Registre
-
Compose ProfileScreen
-
Login
-
Llistar Usuaris
-
Test User
-
-
Aspectes positius del treball realitzat
Alt rendiment i Eficacía a l’hora de completar les tasques, rapida resolucio de problemes.
-
Problemes trobats durant l’sprint
problemes menors que son mes deguts a errors de codi o problemes temporals poc importants de planificacio del sprint.
-
Accions concretes per aplicar millores en els següents sprints
aplicar els coneixements adquirits en el sprint per a solucionar futurs problemescde planificació.
Toni
-
Hores dedicades: 24h
-
Tasques realitzades
-
Test Ad
-
Test Category
-
Llistar Categories
-
LListar Ads per Categories
-
Entitat Ad frontend
-
Entitat Category frontend
-
-
Aspectes positius del treball realitzat
Eficaç i tenacitat a l’hora d’afrontar les tasques
-
Problemes trobats durant l’sprint
Algunes resolucions als problemes i dificultats trobades y superades en les tasques poden generar problemes de codi i son poc intuitius
-
Accions concretes per aplicar millores en els següents sprints
Asegurarse de que les seves resolucions de bugs del codi no afectin a altres parts d’aquest
David
-
Hores dedicades: 34h
-
Tasques realitzades
-
Estructura Packages Graddle a Android Studio
-
Test Category (Fix)
-
Test Ad (Fix)
-
Test User (Fix)
-
Asciidoc memoria sprint 1
-
-
Aspectes positius del treball realitzat
Eficacia a l’hora de resoldre errors de codi i qualitat en aquestes resolucions
-
Problemes trobats durant l’sprint Baixa asistencia a clase sobretot a primera hora lo que dificulta la coordinacio i assignació de tasques, problemes de compatibilitat de llibreries com Lombok
-
Accions concretes per aplicar millores en els següents sprints
Aumentar la asistencia a clase y a primera hora aixi com aumentar la coordinacio de tasques
Sprint 2
3. Anàlisi del treball individual.
Carlos
-
Hores dedicades: 22h
-
Tasques realitzades
-
Crear ProfileScreen
-
Recuperar contraseña
-
-
Aspectes positius del treball realitzat
Alt rendiment i Eficacía a l’hora de completar les tasques, rapida resolucio de problemes.
-
Problemes trobats durant l’sprint
No s’han produit errors destacables
-
Accions concretes per aplicar millores en els següents sprints
seguir aplicant els coneixements adquirits en el sprint per a solucionar futurs problemes de planificació.
Toni
-
Hores dedicades: 17h
-
Tasques realitzades
-
Barra navegacio inferior
-
Modificar Ads
-
Crear Ads
-
-
Aspectes positius del treball realitzat
Eficaç i efectiu a l’hora de treballar en grup
-
Problemes trobats durant l’sprint
No hi ha agut porblemes destacables
-
Accions concretes per aplicar millores en els següents sprints
seguir Asegurantse de que les seves resolucions de bugs del codi no afectin a altres parts d’aquest
David
-
Hores dedicades: 19h
-
Tasques realitzades
-
Crear Categories
-
Crear Propostes
-
-
Aspectes positius del treball realitzat
Eficacia a l’hora de resoldre errors del codi i puliment del codi
-
Problemes trobats durant l’sprint
No s’han produit problemes destacables
-
Accions concretes per aplicar millores en els següents sprints
Seguir asistint a clase com ha fet l’ultima setmana y amb el nivell de treball
Sprint 3
3. Anàlisi del treball individual.
Carlos
-
Hores dedicades: 22h
-
Tasques realitzades
-
Crear usuari desde admin
-
-
Aspectes positius del treball realitzat
Alt rendiment i Eficacía a l’hora de completar les tasques, rapida resolucio de problemes.
-
Problemes trobats durant l’sprint
No s’han produit errors destacables
-
Accions concretes per aplicar millores en els següents sprints
seguir aplicant els coneixements adquirits en el sprint per a solucionar futurs problemes de planificació.
Toni
-
Hores dedicades: 13h
-
Tasques realitzades
-
Mostrar info venedor anuncis
-
Logica crear anucnis
-
Resolucio d’errors anuncis Backend
-
-
Aspectes positius del treball realitzat
Eficaç i efectiu a l’hora de treballar en grup
-
Problemes trobats durant l’sprint
No hi ha agut porblemes destacables
-
Accions concretes per aplicar millores en els següents sprints
seguir Asegurantse de que les seves resolucions de bugs del codi no afectin a altres parts d’aquest
David
-
Hores dedicades: 24h
-
Tasques realitzades
-
Llistar Propostes Screen
-
Activar propostes
-
Resolucio d’errors categories Backend
-
-
Aspectes positius del treball realitzat
Eficacia a l’hora de resoldre errors del codi i puliment del codi
-
Problemes trobats durant l’sprint
No s’han produit problemes destacables
-
Accions concretes per aplicar millores en els següents sprints
Seguir asistint a clase com ha fet l’ultima setmana y amb el nivell de treball